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INTRODUCTION 

The Transportable Applications Environment 
Plus (TAE Plus™), developed by NASA’s Goddard 
Space Flight Center, is a portable User Interface 
Management System (UIMS), which provides (1) 
an intuitive WYSIWYG WorkBench for prototyp- 
ing and designing an application's user interface, 
integrated with (2) tools for efficiently implement- 
ing the designed user interface and (3) effective 
management of the user interface during an ap- 
plication's active domain. During the develop- 
ment of TAE Plus, many design and implementa- 
tion decisions were based on the state-of-the-art 
within graphics workstations, windowing system 
and object-oriented programming languages, and 
this paper shares some of the problems and issues 
experienced during implementation. The paper 
concludes with open issues and a description of 
the next development steps planned for TAE Plus. 


TAE PLUS AS A UIMS 

Before presenting TAE Plus as a UIMS it is first 
necessary to define what a UIMS is. The definition 
by Betts et al [1] which is defined in terms of activi- 
ties and purposes best describes the objectives of 
TAE Plus: 

"A User Interface Management System (UIMS) is 
a tool (or tool set) designed to encourage interdis- 
ciplinary cooperation in the rapid development, 
tailoring and management (control) of the interac- 
tion in an application domain across varying de- 
vices, interaction techniques and user interface 
styles. A UIMS tailors and manages (controls) 
user interaction in an application domain to allow 
for rapid and consistent development. A UIMS 
can be viewed as a tool for increasing program- 
mer productivity . " 

TAE Plus is a tool for designing, building and tai- 
loring an application's user interface (UI) and for 
controlling the designed UI throughout the appli- 


cation's execution. The main component of TAE 
Plus is a WYSIWYG user interface designers' 
"WorkBench" that allows an application developer 
to interactively construct the look and feel of an ap- 
plication screen by arranging and manipulating 
"interaction objects" (e.g., radio buttons, menus, 
icons, stretchers, rotators, etc.). 

Once the application's screen has been designed, 
the WorkBench saves the user interface details in 
a resource file. TAE Plus includes runtime ser- 
vices, Window Programming Tools (WPTs), 
which are used by application programs to display 
and control the user interfaces designed with the 
WorkBench. Since the WPTs access the resource 
file during execution, the user interface details 
remain independent from the application code, al- 
lowing changes to be easily made to the look and 
feel of an application without recompiling or re- 
linking the software. To change the user inter- 
face, the designer returns to the WorkBench, dy- 
namically makes the modifications, and the 
resource files are automatically updated. The 
next time the application is run, the modifications 
will be in effect. Figure 1 illustrates the TAE Plus 
structure. 
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Figure 1. TAE Plus Plus Structure 
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In addition to providing the WPT runtime subrou- 
tines, TAE Plus also offers control of interaction 
objects from the interpreted TAE Command Lan- 
guage (TCL). This capability provides an extreme- 
ly powerful means to quickly prototype an applica- 
tion's use of TAE Plus interaction objects and add 
programming logic without the requirement to 
compile or link. 


INTERACTION OBJECTS AS BUILDING 
BLOCKS 


The use of interaction objects offers the application 
designer/programmer a number of benefits with 
the expected payoff of an increase in programmer 
productivity. [2] 

• The interaction objects work together both visu- 
ally and behaviorally to provide a consistent look 
and feel for the application’s user interface. This 
consistency translates into reduced end-user 
training time, more attractive (from a graphic de- 
sign point of view) screens, and an application 
which is easier to use. 


The basic building blocks for developing an appli- 
cation’s user interface are a set of interaction ob- 
jects. All visually distinct elements of a display 
that are created and managed using TAE Plus are 
considered to be interaction objects. Within TAE 
Plus, interaction objects fall into three categories: 
user-entry objects, information objects and data- 
driven objects. User-entry objects are mecha- 
nisms by which an application can acquire infor- 
mation and directives from the end use, and in- 
clude radio buttons, text entry fields, scrolling text 
lists, pulldown menus, and push buttons. Infor- 
mation objects are used by an application to in- 
struct or notify the user, such as contextual on- 
line help information displayed in a scrollable 
static text object or brief status/error messages 
displayed in a bother box. Data-driven objects are 
vector-drawn graphic objects which have been 
"connected” to an application data variable, and 
elements of their view change as the data values 
change. Examples are dials, thermometers, and 
strip charts, The real-time data-driven objects 
are the most recent addition to the TAE Plus inter- 
action object collection and currently, the types 
supported include rotators, stretchers, discretes, 
text and realtime graphs. Figure 2 illustrates the 
current set of TAE Plus interaction objects (which 
are referred to as items in the WorkBench). For 
advanced screen designs, these items can be 
grouped or composed into larger interaction ob- 
jects, called panels by the WorkBench. 
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Figure 2. Current set of TAE Plus interaction objects 


• Interaction objects provide a common frame- 
work for diverse sets of application programs, and 
serve as a base set of well-documented standards 
for user interfaces in systems composed of many 
separate application programs. 

• The set of user entry interaction objects covers 
most common data entry and manipulation 
needs, allowing the application programmer to 
spend more time on the content of the application 
program. The data driven interaction objects pro- 
vide a standard means of displaying realtime data 
graphically. The object architecture also enables 
quick development and addition of new interaction 
objects into the TAE Plus object library. 

• The interaction objects have been thoroughly 
tested and debugged, allowing the programmer to 
spend more time testing the application, and less 
time verifying that the user interface behaves cor- 
rectly. This is particularly important considering 
the complexity of some of the objects, and the pro- 
gramming effort it would take to code them 
scratch. 


WORKBENCH SCENARIO 

The WorkBench provides an intuitive environ- 
ment for defining, testing, and communicating 
the look and feel of an application system. As a de- 
signer tool, it provides the following key features: 

• Customization and direct manipulation of 
user interaction objects 

• Application code generator 

• Capability to dynamically define 

’’connections” between interaction objects 

• Rehearsal capability to "try out” sequencing 
of the user interface design 

• Icon editor and support for raster objects 

• Undo capability 

• Help icon/button on-line support 

• Capability to dynamically draw and define 
data-driven graphic objects 

Let’s walk through a simple design scenario to get 
a feel for how the WorkBench operates. The appli- 
cation is a hardware monitoring task for a satel- 
lite data handling facility and the designer is go- 
ing to layout the user interaction in which the 
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Figure 3. Hand-drawn sketch of application s 
user interface to be created with WorkBench 
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Figure 5. Defining the interaction 
objects to reside in a panel. 


operator is prompted for a hardware channel 
number. Once the operator selects a channel, a 
new panel appears with a realtime sliding bar ob- 
ject displaying the amount of data flowing 
through the channel. Figure 3 shows a rough 
sketch of the two panels which are to be designed 
with the WorkBench in this scenario. 

Functionally, the WorkBench allows an applica- 
tion designer to dynamically lay out an application 
screen, defining its static and dynamic areas. 

The tool provides the designer with a choice of pre- 
designed interaction objects and allows for tailor- 
ing, combining and rearranging of the objects. To 
begin the session, the designer needs to create the 
base window into which interaction objects will be 
specified. He/she selects New Panel from the 
main WorkBench menu, which displays the panel 
specification panel (Refer to Figure 4) where the 
designer specifies presentation information, such 
as the title, scroll option, font, color, and optional 
on-line help for the panel Monitor. 

The designer is now ready to define the interaction 
items to reside in the panel. He/she selects New 
Item from the WorkBench main menu and is pre- 
sented with the item specification window. The de- 
signer defines both the presentation information 
and the context information. The item specifica- 
tion window has an associated Constraints (i.e., 
context) window within which the labels for each 
entry of a radio button bank object are specified 
(refer to Figure 5). For the scenario we are follow- 
ing here, the designer has created a radio button 
bank for the channel numbers, a cancel and okay 
button and a panel help icon. For icon support, 
the WorkBench has an Icon Editor, within which 
an icon can be drawn, edited and saved. 

The designer also has the option of retrieving a 
"palette” of items (by selecting File.. ..Include from 
the WorkBench menu). From this collection of 
previously created items, the designer can select 
and copy appropriate objects. The ability to reuse 
items saves programming time, facilitates trying 
out different combinations of items in the prototyp- 
ing process, and contributes to standardization of 
the application s look and feel". If an application 
system manager wanted to ensure consistency 
and uniformity across an entire application's UI, 
all developers could be informed to use only items 
from the applications palette of common items. 

The designer goes through the same process to 
build the realtime display panel, DataFlow . This 
simple panel is made up of a data-driven stretcher 
item, selected from a pre-defined pallete of ’output 
objects”, and a quit button. The WorkBench pro- 
vides a drawing tool [5] within which the static 
background and dynamic foreground of a data- 
driven object can be drawn, edited and saved. 

Once the object is created, the designer identifies 
presentation attributes for the object (i.e. the color 
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thresholds, maximum/minimum, delta). 

Most often an application’s UI will be made up of 
a number of related panels, sequenced in a mean- 
ingful fashion. Through the WorkBench, the de- 
signer defines the interface "connections". These 
links determine what happens when the user se- 
lects a button or a menu entry. The designer atta- 
ches "events" to interaction items and thereby des- 
ignates what panel appears and what program 
executes when an event is triggered. Events are 
triggered by user-controlled I/O peripherals (e.g., 
point and click devices or keyboard input). In Fig- 
ure 6, the designer has specified links causing the 
Dataflow panel to appear when the end user se- 
lects the option marked Channel 1 and the process 
Flowcompute to be executed. In turn, Flowcom- 
pute is the application process containing the 
data variable that drives the variations in appear- 
ance of the item BarSlide . 

TAE Plus also offers an optional help feature 
which provides a consistent mechanism for sup- 
plying application specific information about a 
panel and any interaction items within the panel. 
In a typical session, the designer elects to edit a 
help file after all the panel items have been de- 
signed. Clicking on the edit help option brings up 
a text editor window in which the appropriate in- 
formation can be entered. The designer can then 
define any button item or icon item to be " the" 
help item for the panel (in the scenario we are fol- 
lowing, it would be the Help icon in the panel 
Monitor). During the application operation, when 
the end-user clicks on the question mark item, 
the cursor changes to a The end-user then 
clicks on the panel itself or any item in the panel 
to bring up a help panel containing the associated 
help text. 



Figure 6. 

Using the WorkBench to define "connections". 


Having designed the layout of panels and their at- 
tendant items and having threaded the panel and 
items according to their interaction scenario, the 


designer must then be able to preview (i.e., to re- 
hearse) the interface's operation. With this poten- 
tial to "test drive" an interface, to make changes, 
and to dry-run again, iterative design becomes 
part of the prototyping process. When the design- 
er selects the rehearse option (by selecting Utili- 
ty.. ..Rehearse from the WorkBench Menu), the 
screen is cleared and the WorkBench goes 
through the entire sequence as if the application 
were executing. With the rehearsal feature, the 
designer can evaluate and refine both the func- 
tionality and the aesthetics of a proposed interface. 
After the rehearsal, control is returned to 
wherever the designer left off in the WorkBench 
and he/she can either continue with the design 
process or save the defined UI in a resource file 
(by selecting File.. ..Save from the WorkBench 
Menu). 

Developing software with sophisticated user inter- 
faces is a complex process, mandating the support 
of varied talents, including human factors experts 
and application program specialists. Once the UI 
designer (who may have limited experience with 
actual code development) has finished the UI, he/ 
she can turn the saved UI resource file over to an 
experienced programmer. As a further aid to the 
application programmer, the WorkBench's 
"generate" feature (Utility....Generate) produces a 
fully annotated and operational body of code 
which will display and manage the entire Work- 
Bench designed UI. Currently, source code gen- 
eration of C, Ada and TCL are supported, with 
bindings for Fortran and C++ expected in later 
TAE Plus releases. The programmer can now add 
additional code to this template and make a fully 
functional application. Providing these code 
"stubs" helps in establishing uniform program- 
ming method and style across large applications 
or a family of interrelated software applications. 

WINDOW PROGRAMMING TOOLS (WPTs) 

The Window Programming Tools (WPTs) are a 
package of application program callable subrou- 
tines used to control an application’s user inter- 
face. Using these routines, applications can de- 
fine, display, receive information from, update 
and/or delete TAE Plus panels and interaction ob- 
jects (refer to Figure 7 for a current list of WPT). 
WPTs support a modeless user interface, mean- 
ing a user can interact with one of a number of in- 
teraction objects within any one of a number of 
displayed panels. In contrast to sequential mode- 
oriented programming, modeless programming 
accepts, at any instance, a number of user inputs, 
or events. Because these multiple events must be 
handled by the application program, event-driven 
programming can be more complex than tradi- 
tional programming. TheWorkBench’s auto- 
generation of the WPT event loop reduces the risk 
of programmer error within the UI portion of an 
applications’ implementation. 
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Figure 7. The Window Programming Tools (WPTs ) 


The WPTs utilize the X Window System™ [10] as 
its base windowing system. One of the strengths of 
X is the concept of providing a low-level abstrac- 
tion of windowing support (Xlib), which becomes 
the base standard, and a high-level abstraction (X 
toolkits), which has a set of interaction objects 
(called "widgets" in the X world) that define ele- 
ments of a UTs look and feel. The current version 
of TAE Plus (V3.2) is implemented with the latest 
release of X (X11.3) using the Xray toolkit, which 
was distributed with earlier versions of X. We are 
rewriting our WPTs to utilize the X Toolkit, which 
is becoming a de facto toolkit standard. The initial 
approach is to base our default set of interaction 
objects on the HP widget set delivered with the ge- 
neric M.I.T. delivery of X (and which is in the 
public domain) while supporting an open archi- 
tecture that allows adding to the widget set. A 
’ cookbook" explaining the steps to be taken to re- 
place/add widgets and update the WorkBench is in 
progress. This will enable TAE Plus to be used for 
designing and managing the user interface that 
adheres to whatever UI style is defined by an ap- 
plication group to be their preferred widget set. 

The WPTs also provide a buffer between the appli- 
cation program and the X Window System servic- 
es. For instance, to display a WorkBench- 
designed panel, an application makes a single call 
to Wpt_NextPanel. Thus single call translates into 
a function that consists of about 2800 lines of C 
code and makes about 50 calls to X Window Sys- 
tem routines. For the majority of applications, the 
WPT services and objects supported by the Work- 
Bench provide the necessary user interface tools 
and save the programmer from having to learn 
the complexities of programming directly with X. 
This can be a significant advantage, especially 
when considering that the full set of 17 Wpt rou- 
tines consist of 5800 lines of C code and make a to- 
tal of between 300-400 X calls. 


PROTOTYPING IN TAE COMMAND 
LANGUAGE (TCL) 

To provide an easy method for displaying and ma- 
nipulating the newly designed user interface, we 
created a simple set of commands ("WPT" com- 
mands) within the TAE Command Language 
(TCL). 

TCL offers a high-level set of commands used to 
invoke and manage application functions. Com- 
mands can be invoked dynamically during an in- 
teractive session or used to build command proce- 
dures. An advantage TAE Plus has over some 
other UIMS is that it does not just support the 
user interface component of an application, but 
has a full set of integrated tools to fully support an 
application, either a prototype or an operational 
version. These services include parameter manip- 
ulation, message logging, logon/logoff procedure, 
data file I/O, operating system services, scripting 
capability, session logging, procedure building 
capability, on-line help, and user-site tailoring of 
TAE Plus commands. Because user interface tools 
are integrated with general purpose application 
management services, the application need not be 
tightly tied to a particular operating system or 
computer. 

Since TCL is an interpreted language, the com- 
mands can be used to prototype an application 
without having to recompile or relink every time a 
change is made. Just as with WPT routines used 
by application programs, the WPT commands can 
be used to directly define panels and items, or they 
can be used to access WorkBench-generated re- 
source files that contain pre-defined panels and 
items. While the intended use of these commands 
is for prototyping, if the overhead performance of 
executing TCL commands is acceptable, then 
command procedures using WPT commands 
would be appropriate for operational systems. 


TAE PLUS ARCHITECTURE 

The TAE Plus architecture is based on a total sep- 
aration of the user interaction management from 
the application- specific software. The current im- 
plementation is a result of having gone through 
several prototyped versions of a WorkBench and 
graphic support development during the 1986-87 
period, as well as building on an exisiting appli- 
cation management system, the original TAE (af- 
fectionately referred to as "TAE Classic"). [9] TAE 
Classic architecture, which was designed in 1980, 
was based on a total separation of the user interac- 
tion in a much stricter sense than the TAE Plus 
implementation. All user dialogue was directed 
through a terminal monitor , including dialogues 
initiated from within an application. This central 
control of the UI easily facilitated the goal of pro- 
viding a consistent look and feel across an applica- 
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tion, but was limited to an ASCII terminal. 

The advent of the graphic workstation inspires 
more elaborate user interfaces and a closer inter- 
relationship between the application program and 
the UI. The TAE architecture was enhanced to al- 
low for an application to directly control the user 
interactions, while still maintaining presentation 
independence (i.e., an application doesn't need to 
know any of the details as to how a request for data 
is actually being presented to the user, only what 
the data is). Figure 8 illustrates how the TAE Plus 
structure maintains Ul/appli cation independence 
while providing run-time services to control and 
manipulate the user interactions from within an 
application. 
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Figure 8 . 

TAE Plus architecture maintains separation 
of UI and application elements 


SELECTION OF AN IMPLEMENTATION 
LANGUAGE 

TAE Classic is implemented in the C program- 
ming language, which has proven to be an effi- 
cient and standard language across different 
hardware platforms, thus allowing for the porting 
of TAE source code with reasonable ease. Howev- 
er, we felt a "true'’ object-oriented language 
would provide us with the optimum environment 
for implementing the TAE Plus graphical user in- 
terface capabilities. (See Chapter 9 of Cox [3] for a 
discussion on the suitability of object-oriented lan- 
guages for graphical user interfaces.) 

In early 1987, before committing to an object- 
oriented language and as a means of demonstrat- 
ing the utility of the X Window System in our 
UIMS concept, we built a rapid prototype of TAE 
Plus, using Smalltalk™ to implement the Work- 
Bench. This proved to be a beneficial learning ex- 
perience. The prototype demonstrated that object- 
oriented programming is a productive and effec- 
tive method for building user interfaces. Al- 
though Smalltalk enabled us to generate a proto- 
type in a timely manner, several concerns did 
surface during the implementation. For instance, 


at the time of the prototyping effort, Smalltalk was 
not based on the X Window System, which meant 
the WorkBench and the WPTs had different imple- 
mentations of the interaction object functions, 
pother concern with the Smalltalk implementa- 
tion was that the designer had to have some un- 
derstanding of Smalltalk's interface conventions — 
not a desirable feature since the user interface for 
applications operating in the TAE Plus environ- 
ment would have a different set of conventions im- 
posed by an X-based Window Manager. The issue 
of distribution of TAE Plus with a Smalltalk appli- 
cation was also a problem. With TAE, distribution 
only involves acquiring a license from COSMIC™ 
(NASA’s distribution center), but for a site to run 
the WorkBench, they would also need a Smalltalk 
license. The limited use of Smalltalk in our user 
community made this undesirable. For these and 
other reasons [15] we looked at other languages 
for the operational implementation of the Work- 
Bench . 

Though the X Window System is written in C, we 
did not want to constrain ourselves to a procedure- 
based language, especially in light of the power of 
C++ and Objective C, and the fact that interfaces 
from these object-based languages exist to the X 
runtime library. For the past several years, we 
have closely followed the C++ versus Objective C 
debate. The Objective C argument is strong - the 
language is a marriage of two powerful languages 
(Smalltalk and C), and provides much of the 
Smalltalk elegance without severe performance 
penalties. We selected C++, however, for several 
reasons [15]. For one, C++ seems to be a 
cleaner language (i.e., it is a conceptually 
strong expansion of C) and is becoming increas- 
ing popular within the object -oriented program- 
ming community. Another strong argument for 
using C++ is the growing availability of existing 
public domain X-based object class libraries. Uti- 
lizing an existing object library is not only a cost 
saver, but also serves as a learning tool, both for 
object-oriented programming and for C++. Deliv- 
ered with the X Window System is the Interviews 
C++ class library and a drawing utility, idraw , 
both of which were developed at Stanford Universi- 
ty. [4,5] The Interviews C++ class library has 
many attractive features. The class structure has 
gone through several major iterations and the 
current design is clean. The idraw utility is a so- 
phisticated direct manipulation C++ application, 
which allows the WorkBench to create, edit and 
save the graphical data-driven interaction objects. 

Many of the current implementations of C++ com- 
pilers are pre-processors generating standard C 
code, thus enabling the operational TAE Plus code 
to be delivered in C code and allowing for ease in 
porting. With this option and by utilizing sophisti- 
cated public domain software packages (X Win- 
dow System, Interviews, and idraw) we avoid re- 
quiring our user community to purchase any 
additional software licenses or compilers. 


6 


ORIGINAL PAGE IS 
OF POOR QUALITY 





Because of NASA’s commitment to use Ada™ for 
all Space Station software development, the ques- 
tion arises "why not Ada"? We do not consider 
Ada a purely object-oriented language. [3,11,12,17] 
As mentioned earlier, we felt that the TAE Plus 
development would be better served by a "pure" ob- 
ject-oriented language — one that supports data 
encapsulation, inheritance and polymorphism. 
These are the features associated with the type of 
object-oriented programming supported by Small- 
talk and C++. Since TAE Plus software services 
can be accessed by Ada applications, we feel that 
implementing the TAE Plus environment in a 
pure object-oriented language is the most effective 
approach at this particular time. 

PORTABILITY and MAINTAINABILITY 

TAE is designed to be portable. At present, TAE 
Classic is successfully operating on 14 Unix-based 
computers, VAX/VMS and the IBM/VM environ- 
ment. TAE Plus base development is being done 
on a Sun workstation under Unix. As of February 
1989, it is also operational under Unix on the Apol- 
lo, VaxStation II (Ultrix), HP9000, Masscomp and 
the Macintosh II (A/UX). Ports are in progress 
for the IBM RT and IBM PS/2 under AIX and the 
VAX under VMS. TAE Classic has over 230 in- 
stallations, of which 64 are NASA. The current 
beta version of TAE Plus is located at over 100 
world-wide beta sites, including at least 30 NASA 
installations. 

Every system is maintainable; how easy it is to 
maintain is the issue. When a UIMS is used as a 
tool to build and support an application’s user in- 
terface, there is a legitimate concern about the ap- 
plication’s dependency on a "black box". (Since an 
application program's UI control is isolated in the 
UIMS, it is frequently perceived by application 
programmers as a "black box". [6]) The UIMS ar- 
chitecture assure developers that corrections and 
upgrades to itself will have a minimal impact 
within the application domain. We knew when we 
began that TAE Plus was targeted for wide appli- 
cation utilization and for different machines, so 
ease of maintenance has always been important. 
By providing the application callable WPTs and 
WPT function commands, applications are isolat- 
ed from the windowing system, and thus, if in a 
few years a newer, faster, fancier windowing 
standard shows up, only the WPTs require updat- 
ing or rewriting; the application code is not affect- 
ed. In effect, this is what were doing with the re- 
write of the WPTs to use the XI 1 Xtoolkit 
intrinsics. All applications, as well as the Work- 
Bench, will get enhanced capability and perfor- 
mance without making any changes to them- 
selves. 

User support is another facet of maintainability. 
Since the first release of TAE Classic in 1981, 


we have provided user support through a fully 
staffed Support Office. This service has been one 
of the primary reasons for the success of TAE. 
Through the Support Office, users receive an- 
swers to technical questions, report problems, and 
make suggestions for improvements. In turn, the 
Support Office keeps users up-to-date on new re- 
leases, provides training sessions, and sponsors 
user workshops and conferences. This exchange 
of information enables the Project Office to keep 
the TAE software and documentation "in working 
order" and, perhaps most importantly, take ad- 
vantage of user feedback to help direct our future 
development. 


NEXT STEPS 

The current TAE Plus provides a powerful and 
much needed tool for the continuum of software 
engineering — from the initial design phases of a 
highly interactive prototype to the fully operational 
application package. However, there is still a long 
list of enhancements and new capabilities that we 
will be adding to TAE Plus in future releases. 
Features included on the "Wanted List" are exten- 
sions to the interaction objects, particularly in the 
data-driven object category; integration with the 
Open Software Foundation s (OSF) User Environ- 
ment Component (UEC); direct manipulation sup- 
port for application programs; ports to new work- 
station platforms; on-line tutorial and training 
tools; introduction of hypermedia technology; inte- 
gration of expert system technology to aid in mak- 
ing user interface design decision; and imple- 
mentation of additional user interface designer 
tools, such as a WYSIWYG graph builder. 


CONCLUSION 

Building large scale interactive systems has been 
a regular activity at NASA/Goddard Space Flight 
Center (GSFC) since the transition from card 
readers to interactive terminals. Although the ap- 
plications vary from on-board flight instrument 
command and control to scientific data analysis, 
they have all required software to support the com- 
munication between the human user and the ap- 
plication tasks. In the early 1980 s, GSFC sought 
to capitalize on common requirements in human- 
computer interaction by building TAE Plus Clas- 
sic, a powerful tool for quickly and easily building 
consistent, portable user interfaces in an interac- 
tive alphanumeric terminal environment. With 
the emergence of sophisticated graphic worksta- 
tions and the subsequent demands for highly in- 
teractive systems, the user interface becomes 
more complex and includes multiple window dis- 
plays, the use of color, graphical objects and icons, 
and various selection techniques. Traditional UI 
paradigms give us only improvished models and 
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guidelines; they are inadequate for what can be 
accomplished with the new technology. Prototyp- 
ing of different user interface designs, thus, be- 
comes an increasingly important method for sta- 
bilizing concepts and requirements for an 
application. At GSFC, we had the requirement to 
provide a tool for prototyping a visual representa- 
tion of a user interface, as well as establish an in- 
tegrated development environment that allows 
prototyped user interfaces to evolve into operation- 
al applications. We feel TAE Plus is fulfilling this 
role by providing a usable, generalized, portable 
and maintainable package of development tools. 
TAE Plus is an evolving system and its develop- 
ment will continue to be guided by user-defined re- 
quirements. To date, each phase of TAE Plus's ev- 
olution has taken into account advances in virtual 
operating systems, human factors research, com- 
mand language design, standardization efforts 
and software portability. With TAE Plus's flexibil- 
ity and functionality, we believe it can contribute to 
both more advances and more standardization in 
user interface management system technology. 


ACKNOWLEDGEMENTS 

TAE Plus is a NASA software product being devel- 
oped by the NASA/Goddard Space Flight Center 
and by Century Computing, Inc. The work is 
sponsored by the NASA Office of Space Science 
and Applications and the Office of Space Opera- 
tions. Special thanks to Dr. Patricia Carlson for 
her quality editing and to the TAE Plus Support 
Office staff for their tireless service to the TAE 
Project. 

TAE is a registered trademark of National Aero- 
nautics and Space Administration (NASA). It is 
distributed through NASA's distribution center, 
COSMIC. For further information, contact the 
TAE Support Office at GSFC, (301) 286-6034. 


REFERENCES 

1. Betts, B., Burlingame, D., Fischer, G., Foley, J., 
Green, M., Kasik, D., Kerr, S., Olsen, D., Thom- 
as, J., "Goals and Objectives for User Interface 
Software", COMPUTER GRAPHICS, 21:2, 1987. 

2 .Bleser, Teresa, "TAE Plus Style Guide", 

NASA Contractor Document, February 1989. 

3. Cox, Brad J., OBJECT ORIENTED PROGRAM- 
MING, AN EVOLUTIONARY APPROACH, Ad- 
dison-Wesley Publishing Company, Reading, 
Massachusetts, 1986. 

4. Linton, Mark, Calder, Pa til R., "The Design 
and Implementation of Interviews", Proceedings 
of the C++ Workshop, USENBt, November, 1987, 
pp.256-273. 


5. Linton, Mark A., Vlissides, John M., Calder, 
Paul R., "Composing User Interfaces with Inter- 
views", IEEE COMPUTER, February, 1989 

6. Lowgren, Jonas, "History, State and Future of 
User Interface Management Systems", SIGCHI 
BULLETIN, 20:2, 1988. 

7. Myers, B., "Gaining General Acceptance for 
UIMS", COMPUTER GRAPHICS 21:2, 1987. 

8. Olsen, D., " Larger Issues in User Interface 
Man agement", COMPUTER GRAPHICS 21:2, 
1987. 

9. Perkins, D.C., Howell, D.R., Szczur, M.R., "The 
Transportable Applications Executive - an inter- 
active design-to-production development system", 
DIGITAL IMAGE PROCESSING IN REMOTE 
SENSING, edited by J-P Muller, Taylor & Francis 
Publishers, London, 1988. 

10. Scheifler, Robert W., Gettys, Jim., "The X Win- 
dow System", MIT Laboratory for Computer 
Science, Cambridge, MA., October 1986 

11. Schmucker, Kurt J., OBJECT-ORIENTED 
PROGRAMMING FOR THE MACINTOSH, Hay- 
den Book Company, Hasbrouck Heights, New Jer- 
sey 1986. 

12. Seidewitz, Ed., "Object-Oriented Programming 
in Smalltalk and Ada", Proceedings of the Object- 
Oriented Programming Systems, Languages and 
Applications (OOPSLA) Conference, October, 

1987. 

13. Space Station Program Office, "Space Station 
Information System User Support Environment 
Functional Requirements", Final Draft, JSC 
30497, April, 1987 

14. Stroustrup, Bjame, THE C++ PROGRAM- 
MING LANGUAGE, Addison-Wesley Publishing 
Company, Reading, Massachusetts, 1987. 

15. Szczur, Martha R., Miller, Philip, 
"Transportable Applications Environment (TAE) 
Plus: Experiences in "Objectively Modernizing a 
User Interface Environment", Proceedings of the 
Object-Oriented Programming Systems, Languag- 
es and Applications (OOPSLA) Conference, Sep- 
tember 1988 

16. TAE Plus V3.2 Documentation Set, Century 
Computing, Inc., NASA Contractor Documenta- 
tion, January 1989 

17. Wegner, Peter, "Dimensions of Object-Based 
Language Design", Proceedings of the Object- 
Oriented Programming Systems, Languages and 
Applications (OOPSLA) Conference, October, 

1987. 


8 



